Skip to content

Allow type casting of zero-sized array to any dtype #2123

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 3 commits into from
Jul 22, 2025
Merged

Allow type casting of zero-sized array to any dtype #2123

merged 3 commits into from
Jul 22, 2025

Conversation

antonwolfy
Copy link
Collaborator

@antonwolfy antonwolfy commented Jul 14, 2025 •
edited
Loading

This PR allows type casting zero-sized usm_ndarray to any dtype (including larger ones).

  • Have you provided a meaningful PR description?
  • Have you added a test, reproducer or referred to an issue with a reproducer?
  • Have you tested your changes locally for CPU and GPU devices?
  • Have you made sure that new changes do not introduce compiler warnings?
  • Have you checked performance impact of proposed changes?
  • Have you added documentation for your changes, if necessary?
  • Have you added your changes to the changelog?
  • If this PR is a work in progress, are you opening the PR as a draft?

@antonwolfy antonwolfy self-assigned this Jul 14, 2025
@antonwolfy antonwolfy linked an issue Jul 14, 2025 that may be closed by this pull request
Dpctl raises ValueError when changing to larger dtype through the constructor #2119
Closed
@github-actions GitHub Actions
Copy link

github-actions bot commented Jul 14, 2025 •
edited
Loading

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

@github-actions GitHub Actions
Copy link

Array API standard conformance tests for dpctl=0.21.0dev0=py310h93fe807_59 ran successfully.
Passed: 1115
Failed: 6
Skipped: 119

@coveralls
Copy link
Collaborator

coveralls commented Jul 14, 2025 •
edited
Loading

Coverage Status

coverage: 85.89%. remained the same
when pulling 4947f5c on resolve-gh-2119
into e2789db on master.

@github-actions GitHub Actions
Copy link

Array API standard conformance tests for dpctl=0.21.0dev0=py310h93fe807_60 ran successfully.
Passed: 1115
Failed: 6
Skipped: 119

@github-actions GitHub Actions
Copy link

Array API standard conformance tests for dpctl=0.21.0dev0=py310h93fe807_60 ran successfully.
Passed: 1116
Failed: 5
Skipped: 119

ndgrigorian
ndgrigorian reviewed Jul 22, 2025
View reviewed changes
Copy link
Collaborator

@ndgrigorian ndgrigorian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an interesting consequence of this is as follows:

In [1]: import dpctl.tensor as dpt, dpctl, numpy as np

In [2]: x1 = dpt.ones((0,), dtype="i4")

In [3]: x1.usm_data.nbytes
Out[3]: 4

In [4]: x2 = dpt.ones((0,), dtype="i8")

In [5]: x2.usm_data.nbytes
Out[5]: 8

In [6]: x2 = dpt.usm_ndarray(x1.shape, dtype="i8", buffer=x1)

In [7]: x2.usm_data.nbytes
Out[7]: 4

the underlying representation of a size-0 array is actually an array with a single element, which is generally in the size of the original data type

this is mostly an implementation detail, though

ndgrigorian
ndgrigorian approved these changes Jul 22, 2025
View reviewed changes
Copy link
Collaborator

@ndgrigorian ndgrigorian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

above note is interesting but overall, doesn't seem important as long as kernels aren't launched on the memory

LGTM

@antonwolfy
Copy link
Collaborator Author

the underlying representation of a size-0 array is actually an array with a single element, which is generally in the size of the original data type

Interesting that NumPy behaves differently and always returns 0 nbytes:

x1 = np.ones((0,), dtype="i4")
x1.data.nbytes
# Out: 0

x2 = np.ones((0,), dtype="i8")
x2.data.nbytes
# Out: 0

x2 = np.ndarray(x1.shape, dtype="i8", buffer=x1)
x2.data.nbytes
# Out: 0

Probably dpctl should follow the same here.

@antonwolfy antonwolfy merged commit e0dd5bd into master Jul 22, 2025
103 of 123 checks passed
@antonwolfy antonwolfy deleted the resolve-gh-2119 branch July 22, 2025 09:00
@ndgrigorian
Copy link
Collaborator

Probably dpctl should follow the same here.

hard to say—underlying tensor usm_data is always a valid USM pointer, which is the reason for this discrepancy. It's possible that the memory object could be adapted for this special case, but it may not be very important either. In general, working with the underlying memory of a size-0 array is ill-advised.

@antonwolfy
Copy link
Collaborator Author

antonwolfy commented Jul 23, 2025 •
edited
Loading

hard to say—underlying tensor usm_data is always a valid USM pointer, which is the reason for this discrepancy. It's possible that the memory object could be adapted for this special case, but it may not be very important either. In general, working with the underlying memory of a size-0 array is ill-advised.

As per my understanding, it's also a valid pointer in NumPy. It allocates a memory of size 1 in case of zero-space arrays and the same at the deallocation. But in that case it returns nbytes=0.

My previous comment was mainly if we need to return nbytes=0 also in that case.

@ndgrigorian
Copy link
Collaborator

As per my understanding, it's also a valid pointer in NumPy. It allocates a memory of size 1 in case of zero-space arrays and the same at the deallocation. But in that case it returns nbytes=0.

Interesting, I believe CuPy does not, as far as I can tell its memory pointer object is wrapping a nullptr in this case.

@antonwolfy
Copy link
Collaborator Author

Interesting, I believe CuPy does not, as far as I can tell its memory pointer object is wrapping a nullptr in this case.

Yes, it seems so for CuPy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ndgrigorian ndgrigorian ndgrigorian approved these changes

@vtavana vtavana vtavana approved these changes

@vlad-perevezentsev vlad-perevezentsev Awaiting requested review from vlad-perevezentsev vlad-perevezentsev is a code owner

Assignees

@antonwolfy antonwolfy

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Dpctl raises ValueError when changing to larger dtype through the constructor
4 participants
@antonwolfy @coveralls @ndgrigorian @vtavana